home *** CD-ROM | disk | FTP | other *** search
/ PsL Monthly 1993 December / PSL Monthly Shareware CD-ROM (December 1993).iso / prgmming / dos / c / execbep.com / EXECBEEP.DOC < prev    next >
Encoding:
Text File  |  1987-10-30  |  7.3 KB  |  231 lines
  1. #: 137059 S4/Programming (S)
  2.     24-Oct-87  04:11:56
  3. Sb: #EXEC curiosity
  4. Fm: Charles Lazo III 72210,17
  5. To: all
  6.  
  7. I have included in this message the entire listing of a program that I wrote
  8. as a test.  The program works fine.  What I would like to know is why do
  9. mapmem, pmap, and even rmap when you catch it right all show that the program
  10. intercepts int 22h when it was only written to take int 21h?  My own
  11. investigation came to a standstill when I couldn't see where the int 22h
  12. pointed (DOS takes it so debug wouldn't work, Periscope says /v:22 is
  13. illegal.)  <sigh>
  14.  
  15. name execbeep
  16.  
  17. dp        equ    dword ptr
  18. of        equ    offset
  19.  
  20. code        segment
  21.         assume    cs:code
  22.         org    100h
  23.  
  24. begin:        jmp    start
  25.  
  26. old_int21    dw    2 dup(?)    ; former int 21h
  27.  
  28. beep        proc            ; beep the speaker
  29.         push    ax        ; save
  30.         push    cx
  31.         in    al,97        ; get port values
  32.         and    al,0feh        ; turn speaker on
  33.         out    97,al
  34.         mov    cx,55        ; cycles to cx
  35. more_sound:    push    cx        ; save cycles
  36.         xor    al,2        ; flip push/pull
  37.         out    97,al
  38.         mov    cx,111        ; wait
  39. part1:        loop    part1
  40.         xor    al,2        ; flip push/pull
  41.         out    97,al
  42.         mov    cx,111        ; wait
  43. part2:        loop    part2
  44.         pop    cx
  45.         loop    more_sound
  46.         pop    cx        ; restore
  47.         pop    ax
  48.         ret
  49. beep        endp
  50.  
  51. new_int21    proc    far
  52.         cmp    ah,4bh        ; EXEC function?
  53.         je    exec_beep    ; yes, call EXEC, then beep
  54.         jmp    dp cs:old_int21    ; no, pass it on
  55.  
  56. exec_beep:    pushf            ; imitate an interrupt
  57.         call    dp cs:old_int21    ;   in calling EXEC
  58.         call    beep        ; beep after EXEC
  59.         iret            ; return to caller
  60. new_int21    endp
  61.  
  62. start:        mov    ax,3521h    ; get int 21h
  63.         int    21h
  64.         mov    old_int21,bx    ; store offset
  65.         mov    old_int21+2,es    ; store segment
  66.         mov    dx,of new_int21    ; ds:dx -> new int 21h
  67.         mov    ax,2521h
  68.         int    21h
  69.         mov    dx,of start    ; discard excess
  70.         add    dx,0fh
  71.         shr    dx,1
  72.         shr    dx,1
  73.         shr    dx,1
  74.         shr    dx,1
  75.         mov    ax,3100h    ; keep process
  76.         int    21h
  77.  
  78. code        ends
  79.         end    begin
  80.  
  81. #: 137076 S4/Programming (S)
  82.     24-Oct-87  08:37:15
  83. Sb: #137059-EXEC curiosity
  84. Fm: Chip Rabinowitz (MSOFT) 76703,350
  85. To: Charles Lazo III 72210,17 (X)
  86.  
  87. Charles:
  88.  
  89. Interrupt 22 is the MS-DOS Terminate Address.  The currently executing program
  90. under MS-DOS *always* has this address ......
  91.  
  92. Chip
  93.  
  94. #: 137086 S4/Programming (S)
  95.     24-Oct-87  10:25:34
  96. Sb: #137076-#EXEC curiosity
  97. Fm: Charles Lazo III 72210,17
  98. To: Chip Rabinowitz (MSOFT) 76703,350 (X)
  99.  
  100. Ok, true, but pmap, et al always show EXECBEEP as having this vector even if
  101. any number of TSR's are loaded after--how come?
  102.  
  103. Still, it is not true as I stated that "The program works fine."  When I run a
  104. sequence like:
  105.  
  106. C>MARK
  107. C><possibly other loads>
  108. C>RELEASE
  109.  
  110. The machine hangs at the end.  When I tried to bring up Periscope at this
  111. point I got PARITY CHECK 2.
  112.  
  113. #: 137090 S4/Programming (S)
  114.     24-Oct-87  10:58:55
  115. Sb: #137086-EXEC curiosity
  116. Fm: Chip Rabinowitz (MSOFT) 76703,350
  117. To: Charles Lazo III 72210,17 (X)
  118.  
  119. Charles:
  120.  
  121. I dunno, but this could be the problem.  The FLAGS register is significant for
  122. INT 21 ... and your INT21 handler destroys it:  You have:
  123.  
  124. exec_beep:      pushf                   ; imitate an interrupt
  125.                 call    dp cs:old_int21 ;   in calling EXEC
  126.                 call    beep            ; beep after EXEC
  127.                 iret                    ; return to caller
  128.  
  129. if you change this to:
  130.  
  131. exec_beep:      pushf                   ; imitate an interrupt
  132.                 call    dp cs:old_int21 ;   in calling EXEC
  133.                 pushf                   ;save return flags
  134.                 call    beep            ; beep after EXEC
  135.                 popf                    ;original flags return
  136.                 ret 2                   ; return to caller
  137.  
  138. it might work better ....
  139.  
  140. Chip
  141.  
  142. #: 137388 S4/Programming (S)
  143.     25-Oct-87  21:04:23
  144. Sb: #137090-#EXEC curiosity
  145. Fm: Charles Lazo III 72210,17
  146. To: Chip Rabinowitz (MSOFT) 76703,350 (X)
  147.  
  148. Chip, thanks, I made that change, but still no go.  The problem is that int 22h
  149. is made to point to my code exactly 16 bytes from the start of the int 21h
  150. handler.  Ie, normally int 22h points to a location in COMMAND when EXEC is in
  151. effect, but EXECBEEP's interaction with DOS makes int 22h point to a paragraph
  152. beyond the int 21h handler.  This is done by DOS after (or during) the function
  153. 31h termination.  I was able to determine this by using PEPORE, a program that
  154. Don suggested (a popup memory dump program).  It is RELEASE's attempt to
  155. replace the terminate vector to point to EXECBEEP's code that causes the crash
  156. mentioned before (verified by having a valid termination of RELEASE when the
  157. int 22h vector in the vector table kept by MARK was changed to point to its
  158. normal location in COMMAND).
  159.  
  160. Using int 27h termination results in the same effect and so does the direct
  161. replacement of int 21h by storing segment and offset in the int table.
  162.  
  163. At this point the only thing that I can think to do is use PS's run program and
  164. GT after termination of EXECBEEP in two different forms--one which alters int
  165. 21h and one which doesn't--then note any difference in the trace back buffer. 
  166. Have a better suggestion?
  167.  
  168. #: 137396 S4/Programming (S)
  169.     25-Oct-87  21:59:32
  170. Sb: #137388-EXEC curiosity
  171. Fm: Chip Rabinowitz (MSOFT) 76703,350
  172. To: Charles Lazo III 72210,17 (X)
  173.  
  174. Charles:
  175.  
  176. I don't know .. and its been a long day here.  I'll try to look at your code
  177. this week and see if I can find anything.  Give me a nudge Tuesday PM if you
  178. don't here from me.
  179.  
  180. Chip
  181.  
  182. #: 137874 S4/Programming (S)
  183.     28-Oct-87  13:29:28
  184. Sb: #137396-#EXEC curiosity
  185. Fm: Charles Lazo III 72210,17
  186. To: Chip Rabinowitz (MSOFT) 76703,350 (X)
  187.  
  188. Chip,
  189.  
  190. (Whew--that was a long haul!  But in the end it was simple.)
  191.  
  192. Turns out that the EXEC call automatically sets the int 22h vector to the code
  193. immediately succeeding the int 21h call for EXEC while EXEC is in progress.
  194. Presumably because this is the address to which execution will pass if there
  195. is an abnormal termination.  I tried every thing I could think of to get
  196. around this difficulty even (heaven forbid!) changing the code after the EXEC
  197. call into a jump to the 21h handler where it was restored to the original
  198. value before the handler exited (even such drastic action did not work; there
  199. were reentrancy problems).  Finally, taking a break after that fiasco to
  200. collect my thoughts it occurred to me that something which I had thought about
  201. before but rejected (because it does not solve the problem of eg, "Bad command
  202. or file name"--but that's ok!) was in fact the solution.  YOU SIMPLY TRAP THE
  203. RETURN CODE CALL:
  204.  
  205. new_int21       proc    far
  206.                 cmp     ah,4bh          ; EXEC function?
  207.                 je      exec_beep       ; yes, beep, then call EXEC
  208.                 cmp     ah,4dh          ; request to get return code?
  209.                 je      retc_beep       ; yes, beep then get return code
  210.                 jmp     dp cs:old_int21 ; no, pass it on
  211.  
  212. exec_beep:      call    beep            ; beep before EXEC
  213.                 jmp     dp cs:old_int21 ; go do EXEC
  214.  
  215. retc_beep:      call    beep            ; beep after EXEC
  216.                 jmp     dp cs:old_int21 ; go get return code
  217. new_int21       endp
  218.  
  219. Thanks for responding, I appreciate that I can tap your knowledge on these
  220. things.
  221.  
  222. #: 137880 S4/Programming (S)
  223.     28-Oct-87  15:38:46
  224. Sb: #137874-EXEC curiosity
  225. Fm: Chip Rabinowitz (MSOFT) 76703,350
  226. To: Charles Lazo III 72210,17 (X)
  227.  
  228. Anytime I can help, charles.  Thanks for the feedback ...
  229.  
  230. Chip
  231.